\subsection{Executable Representation}
\label{sec:execrep}

The executable portion of the intermediate code will be ``bytecode''
for a stack machine hereinafter known as the GNU Virtual Machine
(GVM).  The stack machine will represent code at approximately the
same level represented by the GIMPLE level of TREE.  The use of a
stack removes any need for pickled pointers to represent expression
trees.  The TREE representation of the executable code can be readily
reconstituted from the stack code.

The GVM will share some features with Sun's Java Virtual Machine (JVM)
and Microsoft's Common Intermediate Language (CIL).  However, there
will also be some important differences:
\begin{description}

\item[portability] Like JVM bytecode, the format of the GVM bytecode
  will be architecture-independent.  However, unlike JVM bytecode, it
  will not be possible to reuse the GVM bytecode from one platform on
  another; for example, the bytecode generated by an IA32 GNU/Linux
  will not be reusable as part of a PowerPC AIX program.
  
\item[executability] Given that the GVM code will be translated into
  executable code, it is highly likely that this code could be
  directly executed.  However, no particular attention will be given
  to make this easy.  What is important is to be able to transport the
  intermediate code efficiently from the compiler to the link time
  optimizer.

\item[verification] Some bytecode formats permit verification; i.e., a
  tool can check that executing the bytecode will not result in
  certain kinds of unsafe behaviors.  The Java bytecode format is
  fully verifiable.  The CIL format provides optional verification.
  The GVM format will not be designed to support verification because
  most of our target languages explicitly permit operations that would
  be considered unsafe by a verifier.

\item[operators] The operators will be drawn from two sets: those
  that manipulate the stack ({\code load, store, duplicate, swap)} and
  the operators used in GIMPLE.

  \begin{note} 
  We believe that it may be useful to add some higher-level operations
  to GIMPLE, such as array operations, virtual functions calls,
  dynamic casts, parallel execution blocks, and high level loops.  To
  the extent that these higher-level operators will facilitate
  additional optimizations, they should be present in GIMPLE, and,
  therefore, in the stack machine.  As GIMPLE evolves, the stack
  machine should evolve in parallel.
  \end{note}

\item[the stack] The stack is an unbounded array of expressions.  It
  will be an invariant of the code generated that the stack will be
  empty at basic block boundaries.  Basic block boundaries will be
  explicitly indicated in the stack machine code.

  JVM and CIL codes utilize a register allocation pass to generate
  their intermediate code. This register allocation obscures the code
  in a way that makes debugging more difficult and requires
  significant resources on both the input and output sides.  Therefore,
  the generation of GVM bytecode will not require register allocation.

\item[blocks] There will be several types of explicit blocks in the
  code stream. These are basic blocks, bind expressions, parallel
  execution blocks.  

\item[the registers] The registers of the GVM correspond one for one
  with the local variables at the GIMPLE level.  Each local variable
  will be assigned an index, and a symbol table will be provided to
  keep the type of each of these temps.  Types will be given as 
  references to the corresponding DWARF-3 DIEs representing those
  types.

\item[types] The stack is dynamically typed.  The type of an element on the
  stack is determined from the operation used to set that item.  The
  result type of a generic operation (e.g., addition) is determined
  from the inputs to that operation.  Some operations (e.g., casts)
  will explicitly indicate the result of the operation.

\end{description}
